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Authors' Abstract 

Most specification languages have a type system. Type systems are hard to get 
right, and getting them wrong can lead to inconsistencies. Set theory can serve 
as the basis for a specification language without types. This possibility, which has 
been widely overlooked, offers many advantages. Untyped set theory is simple and 
is more flexible than any simple typed formalism. Polymorphism, overloading, and 
subtyping can make a type system more powerful, but at the cost of increased com- 
plexity, and such refinements can never attain the flexibility of having no types at 
all. Typed formalisms have advantages too, stemming from the power of mechan- 
ical type checking. While types serve little purpose in hand proofs, they do help 
with mechanized proofs. In the absence of verification, type checking can catch er- 
rors in specifications. It may be possible to have the best of both worlds by adding 
typing annotations to an untyped specification language. 

We consider only specification languages, not programming languages. 
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1 Introduction 



Types have become ubiquitous in computer science. The advantages of typed pro- 
gramming languages are obvious, so most computer scientists assume that they 
should also be used in languages and logics for specification and verification. Some 
computer scientists we have talked to even doubted that an untyped formalism can 
be sound. Types do more good than harm in a programming language: they let the 
compiler catch errors that would otherwise be found only after hours of debugging. 
Specification and verification are different from programming; we do not run spec- 
ifications, and there is no convincing analogy between debugging and verification. 

We begin with two examples illustrating that types are not as benign as they 
may seem to the unwary. We then try to help readers answer the question, should 
the specification language they use be typed? 

As the first example, suppose that a program contains an array A of type 
Nat Nat and two variables i and j of type Nat, where Nat is the type of 
natural numbers. Consider the following question: is the postcondition A[i — j] = 
M.i — j] true if the program terminates with % — j < 0 (so A[i — j] is not type- 
correct)? "It's a run-time error" is not a meaningful answer, since our question is 
whether a mathematical formula is true, and formulas don't run. Indeed, the pro- 
gram might be error-free; we can ask this question even if the expression A[i — j] 
does not appear in the program. In any conventional logic (including the one we 
outline below), the answer is clear — the formula e = e is a tautology for any ex- 
pression e. Now let us examine some popular books that use types and see how 
they answer this question. The books by Chandy and Misra [3] and Manna and 
Pnueli [28], despite their efforts to be rigorous, do not provide an answer. Gries and 
Schneider were more careful in the description of the typed logic in their book [17]. 
Their explicit typing rules tell us that A[i — j] — A[i — j] is not a legal expression. 
Unfortunately, those same rules tell us that (i—j > 0) (A[i — j] — A[i — j]) is 
also an illegal expression. It would appear to be rather awkward to use their logic to 
reason about a program containing the statement if i — j > 0 then A[i — j] : — 0. 
Few other books cope any better with the interactions between types and defmed- 
ness. The book by Apt and Olderog [1] avoids such problems by not allowing the 
type Nat; one has to use the type INT of all integers. It also insists that all func- 
tions be total, even defining division by zero to yield zero. Apt and Olderog do not 
allow you to declare an array indexed by the set {0, . . . , 99}, but they do allow you 
to write x : = 1/0 in place of x : = 0. 

As the second example, consider an algorithm for computing the gcd of (the 
initial values of) the variables m and n. The assertion that the result is the gcd 
of m and n will be expressed by some formula F(m, n). In an untyped for- 
malism such as untyped temporal logic or an untyped version of Dijkstra's wp 
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calculus, correctness of the algorithm for all integers is expressed by the formula 
(to, n e Z) =>■ F(m, n), where Z is the set of integers. In a typed formalism, 
it is expressed by the validity of F(m, n) when to and n are of type INT, an as- 
sertion we write to, n : INT h F(m, n). We would expect that an algorithm for 
computing the gcd of two integers also computes the gcd of two natural numbers. 
In an untyped formalism, this is the case because (to, neZ)4 F(m, n) implies 
(to, n e N) F(m, n), since the set N of natural numbers is a subset of Z. 
However, in many typed formalisms, to, n : INT h F(m, n) does not necessarily 
imply to, n : Nat I- F(m, n). For example, in a typed formulation of the wp 
calculus, wp(n : — n — 1, TRUE) equals TRUE if n has type INT and equals n > 0 
if n has type Nat [16]. 1 Thus, n : INT h u>p(n : — n — 1, TRUE) is valid, but 
n : Nat h wp(n : = n — 1, true) is not. We believe that, in formal versions of 
the logics of Chandy and Misra and of Manna and Pnueli, to, n : INT h F(m, n) 
will not imply to, n : Nat I- F(m, n) for arbitrary F. 

Many type systems have been proposed that handle the first example. We will 
describe the most popular, and point out their costs. The problem posed by the 
second example seems to have gone unnoticed. Our raising of it has elicited two 
kinds of responses from advocates of typed systems. The first is that changing the 
type of a variable in a program changes the program, so there is nothing surpris- 
ing about the example. But the example is about the specification of an abstract 
algorithm, not about programs. We expect any informal description of Euclid's 
algorithm that works for integers to work for natural numbers. It seems reasonable 
to expect the same of a formal description, but types force us to abandon common 
sense and think like a programmer. The other response has been that there is some- 
thing wrong with a formalism in which n : INT h G does not imply n : Nat h G 
for any formula G. One referee even wrote that wp(n : = n — 1, TRUE) isn't a 
formula, but "a meta-theoretic operation on formulas". As far as we know, all pro- 
gramming logics and temporal logics share this problem. In this view, apparently 
these logics are either all flawed, or else they aren't really logics, but are calculi of 
meta-theoretic operations. 

An untyped formalism based on axiomatic set theory, the standard way of for- 
malizing everyday mathematics, can provide a simple, powerful foundation for 
writing formal specifications. For readers not familiar with set theory, Section 2 
describes such a formalism and explains how it avoids the potential inconsistencies 
of naive set theory. Readers already familiar with set theory may find this section 
perfectly obvious. 

'We are using Gries's semantic definition of wp from Chapter 7 [16, page 108], His rule for 
computing wp of an assignment statement in Definition 9.1.1 could be interpreted to mean that 
wp(n := n — 1, TRUE) equals either n > 0 or TRUE, when n has type NAT. The ambiguity arises 
because Gries gives no typing rules. 
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Some computer scientists are so used to thinking in terms of types that they 
find untyped set theory completely unnatural. To them, types express a natural 
classification of objects — a classification that should be enforced by the syntax. 
They feel that we should not be allowed to write a nonsensical formula like 2 n N. 
Some believe that integers and real numbers are completely distinct types, and it 
should make no sense to assert that the integer 2 equals the real number 2 [23]. 

There is nothing inherently natural or unnatural about types or sets. There are 
mathematicians and computer scientists who find untyped set theory to be com- 
pletely natural. To them, not being allowed to write 2 D N is a confusion of syntax 
with semantics — like trying to redefine the grammar of English so "Rocks are car- 
nivores" is not a well-formed sentence. They are happy with the standard mathe- 
matical construction of the real numbers, in which the integers are identified with 
(declared to be) a subset of the reals. They find types to be an unnecessary and 
unnatural complication. 

We eschew philosophical arguments about what is natural. We believe that, as 
Dana Scott once said, "Logic is an experimental science." For us, a formalism is 
a tool, not an end in itself. We are concerned here with working formalisms, those 
intended as a foundation for the varied and often quite large specifications that arise 
in industrial practice, where even a simplified, high-level formal specification of a 
system can be more than 50 pages. The choice of a working formalism should be 
based on pragmatism, not philosophy. Types should be used if and only if they 
help more than they hinder. We explain how they help and how they hinder, so 
readers can make a more informed choice of whether to use them. We also discuss 
the possibility of getting the best of both worlds by overlaying type systems atop a 
basic untyped formalism. 

Section 3 describes the general classes of type systems and how they are used. 
It is followed by a discussion of the pros and cons of typed and typeless formalisms. 
From this discussion, we draw the following conclusions: 

• If a specification language is to be general, it must be expressive. No sim- 
ple type system is as expressive as untyped set theory. While a simple type 
system can allow many specifications to be written easily, it will make some 
impossible to write and others more complicated than they would be in set 
theory. The constructive type theories described in Section 3.6 may be ex- 
pressive enough for writing just about any specification, but they are ex- 
tremely complicated. 

• Any error caught by type checking will be found easily when reasoning about 
a specification. However, large specifications are seldom verified, and type 
checking can catch errors in them that would otherwise go undetected. More- 
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over, mechanical theorem proving with a typed formalism may require less 
human intervention than with untyped set theory. 

• Types serve little purpose in practice unless enforced by mechanical type 
checking. 

These conclusions suggest the possibility of using untyped set theory, either by 
itself or in combination with a type system that poses additional well-formedness 
conditions on formulas. Different type systems could be used for different speci- 
fications, or even for different parts of the same specification. We believe that this 
approach merits further study. 

While types can be helpful for tools that must deal with real applications, they 
serve little purpose in the kind of textbooks we have discussed, which rely exclu- 
sively on hand proofs. In such books, types either unnecessarily restrict the range 
of applications, or else add complications that are masked only by informal pre- 
sentations that sweep them under the rug, 

2 Types are Not Necessary 

Although specification languages may employ esoteric formalisms like temporal 
logic or process algebra, those formalisms are generally based on a more mundane 
assertion language. The formalism's type system, or lack thereof, comes from this 
underlying language. We now sketch an untyped language, based on ZF set theory, 
for specifying data structures and operations on them. 2 It is similar to the language 
mechanized by one of us using Isabelle [36, 39]. 

2.1 Logic 

Our language is based on first-order predicate logic with equality. We also use 
Hilbert's e operator [27], which we call choose. The expression choose x . P(x) 
denotes an arbitrary value x that satisfies P(x), if one exists; otherwise it denotes 
a completely arbitrary value. The choose operator satisfies the following axiom 
schemas (=>■ is implication and = is the boolean operator if and only if). 

(3x.P(x)) P(choose x . P(x)) (1) 
(V x . P(x) = Q(x)) =>■ (choose x . P(x)) — (choose x . Q(x)) 

2 We prefer Zermelo-Fraenkel (ZF) set theory. However, for the purposes of this article, other 
axiom systems such as Bernays-Godel (BG) would serve just as well. Implementors of theorem 
provers might prefer BG to ZF because BG has no axiom schemes. 
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Although choose is seldom mentioned in logic texts, mathematicians implicitly use 
similar operators all the time. Assuming i/0,a mathematician might define l/x 
to be the unique number such that x ■ (l/x) — I. This can be expressed formally 
as 

l/x = choose y . (y e R) a (x ■ y — 1) 

where R is the set of real numbers. To write a specification, we define new op- 
erators in terms of the primitive ones provided by the formalism. We take the 
simple view that definitions are purely syntactic. For example, writing F(x) — 
3y . G(x,y) makes F(e) an abbreviation for 3 y . G(e, y), for any expression e. 
An operator can be defined only in terms of primitive operators and operators that 
have already been defined. (Recursion is discussed below.) Thus, by replacing 
defined symbols with their definitions, any expression can be reduced to one con- 
taining only the primitive operators. A definition cannot introduce unsoundness, so 
we never have to prove a theorem in order to make a definition. Of course, we have 
to prove that the operators we define have the properties we want. For example, we 
define the if/then/else construct by 

if p then t\ else e2 = choose x . (p A (x — e\)) v {->p a (x = e2)) 

From this definition and the axiom schemas (1), we can prove 

(if true then e\ else ei) = ei 

Since choose is permitted in function definitions, the first axiom of (1) yields a 
strong form of the axiom of choice. One can use a more restricted choose operator 
with weaker axioms, but the unrestricted form is more convenient. There seems to 
be no practical reason to avoid the axiom of choice in a formalism for specifying 
and verifying computer systems. 

2.2 Set Theory 

Figure 1 describes a collection of operators from set theory that we have found 
valuable in writing specifications. Some of these operators are defined in terms 
of the others; the rest are primitive. We will not discuss the axioms of set theory. 
When writing and reasoning about specifications, it makes no difference which of 
these operators are taken to be primitive. We need only understand their meanings 
and know that two sets are equal iff they have the same elements. 

Naive informal reasoning about sets can be unsound. It leads to many para- 
doxes [45, pages 60-65], the most famous being Russell's paradox of the set 1Z of 
all sets that are not elements of themselves. This set satisfies 1Z € 1Z iff it satisfies 
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= /e^0Unc\ [set difference] 



{ei, . . . , e n } [Set consisting of elements ej] 

{x e S : P(x)} [Set of elements x in S satisfying P(x)] 

{e(x) : x e S} [Set of elements e(x) such that x in S] 

V(S) [Set of subsets of S] 

[J S [Union of all elements of S] 

(ei, . . . , e n ) [The n-tuple whose i* component is a] 

Si x . . . x S n [The set of all n -tuples with i lh component in Si] 

Figure 1 : The operators of set theory. 

/[e] [Function application] 

dom / [Domain of the function /] 

S — »• T [Set of functions with domain S and range a subset of T] 



[igSh e(x)] [Function/ suchthat/[a;] = e(x) for a; G S] 
Figure 2: Operators for expressing functions 

1Z $ TZ. In axiomatic set theory (such as ZF), paradoxes are avoided by preventing 
the creation of sets that are too big. The Russell set 1Z might be written as the com- 
prehension {x : x $ x], but ZF allows only comprehension over some previously 
constructed set S, as shown in Figure l. 3 

2.3 Functions 

A function is usually defined to be a set of ordered pairs. Formally, one can define 
the operator Apply by 

Apply(J,x) = choose y. (x, y) ef 

and let f(x) be an abbreviation for Apply (J, x). But, it doesn't matter how func- 
tions are defined. We prefer simply to regard the four operators of Figure 2 as 
primitive, where we write f[x] instead of the customary f(x) to distinguish func- 
tion application from operator application. 4 A function / has a domain, which 
is the set written dom /. The set S — ► T consists of all functions / such that 
dom f — S and f[x] e T for all x e S. The notation [x e S \-+ e(x)] is 
used to describe a function explicitly. (We reserve the more familiar A-notation for 

3 S is considered to lie outside the scope of the bound variable x in the expression {x e S : P(x)}, 
so [x e {x} : x £ x\ equals [y e [x] : y g y}. 

4 We could use f(x) for both; simple syntactic rules can determine which is meant. 
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other purposes.) For example, [r e R\{0} i->- 1/r] is the reciprocal function recip, 
whose domain is the set R\{0} of nonzero reals. We can define this function by 

recip[r : R\{0}] = 1/r 

In general, f[x : S] — e(x) defines / to equal [x € S \-> e(x)]. We describe 
recursive function definitions in Section 2.5 below. 

2.4 Functions versus operators 

Functions are different from operators. A function / has a domain, and we define 
the value of f[x] only for elements x in its domain. The expression recip[0], 
which is an abbreviation for Apply (recip, 0), is syntactically a term, so it denotes 
a value. However, we don't know what value. It need not equal 1/0. It need 
not even be a number. But, whatever its value, it must equal recip[2 — 2], since 
2 — 2 equals 0. Functions are just like other values; for example, recip by itself is 
syntactically a term. We can quantify over sets of functions, writing expressions 
such as V/ e (R -> R) . |/|oo > 0. 

Operators are different from functions. (Set theorists call them class functions.) 
Consider the operator [J, where ij 5 is the union of all elements of S. We cannot 
define a function union so that union[S] equals |J S for all sets S. The domain 
of union would have to be a set that contains all sets, and there is no such set. (If 
there were, we would encounter Russell's paradox.) The symbol |J by itself is not 
a term, so it does not denote a value. 

Higher-order operators, which take operators as arguments, pose no problem. 
For example, we can define the operator increasing so that increasing(F) asserts 
that the operator F is increasing under the partial order C. 

increasing(F) = Vi.icF(i) 

However, we do not allow quantification over operators, which would lead to a 
higher-order logic. The string 3J7.R e U (R) is not syntactically well-formed, 
since we can write R e U(R) only if U is an operator, and bound variables are 
terms, not operators. We could combine ZF with higher-order logic, but there is 
little reason to adopt such a complicated formalism. Because we can quantify over 
functions, we have not found quantification over operators to be necessary. 

The distinction between operators and functions exists in ordinary mathemat- 
ics. Mathematicians don't think of [J or e as functions. However, the distinction 
tends to go unnoticed — perhaps because ordinary mathematicians have no generic 
name for what we call operators. 
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2.5 Recursion 



We allow recursive function definitions of the form 

f[x:S] = e(x,f) (2) 

For example, we can define the factorial function fact on natural numbers by 

fact[n:N] = if n = 0 then 1 else n ■ fact[n — 1] (3) 

There are several ways to define (2); perhaps the simplest is to let it be an abbrevi- 
ation for 

/ = choose g . g — [x e S \-+ e(x, g)] 

One can also introduce constructs for defining sets recursively, as well as for defin- 
ing least and greatest fixed points [37]. They can all be translated to simple set- 
theoretic definitions. However, operators, unlike functions, cannot in general be 
defined recursively. 

Of course, one can write silly recursive definitions — for example, replacing 
n — 1 by n + 1 in (3). To prove anything about a recursively defined function, 
we must prove that the recursion is well-founded. The well-foundedness of many 
recursive definitions is obvious enough to be verified automatically. For some def- 
initions, the proof of well-foundedness may be difficult; the question may even 
be undecidable. Well-founded or not, a recursive function definition does define 
some value (though not necessarily a function). A definition can never introduce 
inconsistency. 

2.6 What is 1/0? 

Elementary school children and programmers are taught that 1/0 is meaningless, 
and they are committing an error by even writing it. In set theory, one can give a 
simple answer to the question of what 1/0 is: we don't know and we don't care. 

Let us take 1/0 to be an abbreviation for recip[0], where recip is the reciprocal 
function defined in Section 2.3. Since 0 is not in the domain of recip, we know 
nothing about the value of 1/0; it might equal \fl, it might equal R, or it might 
equal anything else. We don't care what it equals. For example, consider 

(x e R) A (x # 0) =>■ (x ■ (l/x) = 1) (4) 

This formula holds for all values of x. Substituting 0 for x yields the formula 
false =>• (0 • (1/0) = 1), which equals true regardless of the value of 1/0, and 
regardless of whether or not 0 • (1/0) equals 1. The subformula x ■ (l/x) — 1 of 
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(4) may or may not hold; we don't know what 0 • (1/0) or R • (1/R) equal, so we 
don't know whether or not they equal 1. 

One drawback of the don't-care approach is that theorems such as 1/0 — 1/0 
can be proved about undefined quantities. This is avoided by more sophisticated 
approaches. We can introduce a formal notion of defmedness and provide axioms 
for proving that terms are defined [10]. Domain theory goes even further, adding 
a more defined than relation between functions [18]. In our experience [35], the 
benefits of these approaches do not justify their complexity. Abstract Incorpo- 
rated's LAMBDA system [24] moved from a defmedness logic [42] to conventional 
higher-order logic for similar reasons. 

2.7 Examples 

The data structures and related operations found in programming and specification 
languages are easily represented in set theory. We show how to represent three of 
these structures: finite lists, records, and objects. 

2.7.1 Finite lists 

We represent a finite list of length n as a function with domain 1 . . n, the set 
{i e N : 1 < i < n} of natural numbers from 1 through n. The set List(L) of all 
finite lists with elements in the set L is just equal to |J{(1 . . n) -> L : n e N}. 
The length Len(s) of a finite list s is defined by 

Len(s) — choose n . (n g N) A (dom s — 1 . . n) (5) 

List and Len are operators; they cannot be functions. For them to be functions, 
their domains would have to consist of all sets and all finite lists, respectively, 
neither of which forms a set. 

2.7.2 Records 

We represent a record as a function whose domain is a finite set of strings. For 
example, the set of all records that consist of a ptr field that is a natural number 
and a sq field that is a list of natural numbers is 

{r e ({"ptr", "sq"} -> N U List(N)) : r["ptr"] e N a r["sq"] e List(N)} 

We let r.str be an abbreviation for r["str"], for any string str. 

In set theory, one can define many useful operators on records that are not ex- 
pressible in conventional programming languages. For example, suppose T is a 
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"record type" — a set of records all having the same components — and r an arbi- 
trary record. We can define the operator Copy so that Copy(T, r) is a record t in 
T such that t.c equals r.c for any component c common to both t and r. We first 
define Any(T) to equal choose t A e T and then define Copy(T, r) to equal 

[c e dom Any(T) i->- if c € dom rthen r[c] else Any(T)[c]] 
2.7.3 Objects 

Objects and classes generalize the concept of records and record types. One can 
define the class C of all objects with a cnt field and the method add 1 that, for any 
object o in this class, returns the object that is the same as o except with its cnt 
field incremented by 1. 

To represent objects in set theory, we first define some elementary sets of val- 
ues, including the set of all strings, the set of all integers, and any other desired sets 
of primitive data values. We next define (by transfmite recursion) a set U of values 
to be the smallest set containing all of these elementary sets such that if S and T 
are elements of U, then S — > T, V(S), and all the elements of S are also elements 
of U. The set O of objects is then the set of all elements in U that are records. 

The class C of all objects with a cnt field is represented by the set { o e 0 : 
"cnt" e dom o}, and the method addl by the function with domain C such that 
addl[o] equals the function 

[ s e dom o i— > if s — "cnt" then o["cnt"] + 1 else o[s] ] 

for all o e C. In general, a class is a set of objects, and a method is a function 
whose domain is a class. The set M of methods is the union of all sets S — ^ U such 
that S C O. (Since classical mathematics has no notion of assignment, objects 
defined in this way resemble objects in a functional programming language rather 
than an imperative one.) 

Some object-oriented languages allow methods to be associated with individual 
objects. Methods are not elements of U, so they cannot appear as fields of an 
object. 5 Thus, a field o.m of an object o cannot equal addl. However, we can 
define a set N of method names with N C U and a function \x in N — ► M such 
that /x[o.m] equals addl. For example, we could let N be a set of strings, define 
\x such that /x["add1 "] = addl, and let o.m equal "addl ". In principle, we could 
define N to be the set of strings in some language for describing methods, and 
define /x to be a "compiler" for that language. In practice, any specification will 
use only a small set of distinct methods, which can be assigned arbitrary names 
like "add 1". 

5 Because the set S -> S is always bigger than the set S, there is no way to construct a set of 
objects so that any method can be a field of some object. 
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3 Typed Formal Languages 



Types in programming languages are valuable but not essential. Two programming 
languages can be quite similar except for the use of types — for example, C and 
BCPL, or ML and Lisp. Programming languages use type checking to catch errors 
at compile time and to improve run-time efficiency. Declaring A to be an array 
indexed by 1 . . 4 allows the compiler to assign storage only for four array elements 
and to detect yl["two"] to be an error. 

Types in a typed logical formalism play an essential role. If we remove type 
checking, we almost certainly make the logic inconsistent and therefore useless. 
One reason for adopting a typed logic is indeed to catch errors, but type checking 
cannot just be disabled when it is inconvenient. 

There is usually no obvious translation between the typed and the untyped 
worlds. Although basic types like Nat and INT can be identified with particular 
sets, more general types cannot. 

One could consider ZF to be a typed formalism with the two basic types Set 
and BOOL, and its syntax could be formulated as typing rules. For example, U 
would have type Set x Set ->• Set and V would have type Set Set, making 
SUV illegal because it doesn't type check. But practically all expressions would 
have type Set. By a typed formalism, we mean one with many basic types, such 
as NAT (natural numbers) and REAL (real numbers). 

The most popular typed formalism is higher-order logic, also known as simple 
type theory. Versions of it have been mechanized in a number of proof assistants, 
including HOL [15], Isabelle/HOL [38], and PVS [34]. We will focus on higher- 
order logic, but we will also outline alternatives to it. 

3.1 Typed Set Theory 

Whitehead and Russell invented types early in this century to prevent the paradoxes 
of naive set theory [45]. Their work contains all the elements of modern higher- 
order logic. The key idea is that a set must have a different type from its elements. 
If S is a set, then it has a type of the form Set(t); we may write x e S only if x 
has type r. The formula x $ x, which occurs in the definition of the Russell set 1Z, 
is illegal because x cannot simultaneously have types r and Set(t). 

All elements of a set must have the same type. Many constructions used in un- 
typed set theory violate this restriction. They mostly have the flavor of encodings. 
For example, in ZF one often defines the ordered pair (a, b) to be {{a}, {a, b}}, 
and the natural number n to be the set {0, . . . , n — 1}. Higher-order logic uses 
different definitions and can express much of mathematics easily. Occasionally, 
cumbersome constructions are needed to get around its type constraints. 
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3.2 Polymorphism 

As programmers know, an unduly restrictive type system can make it hard to write 
perfectly reasonable expressions. Whitehead and Russell realized that a type disci- 
pline has to be flexible. The proof of a theorem like x e {x} must not depend on the 
type of x. They invented (in 1910!) the concept we now call polymorphism, which 
they called typical ambiguity. The premise of polymorphism is that we should not 
have to think about types that are irrelevant, and that most type constraints should 
be implicit. Whitehead and Russell never even bothered to invent a notation for 
types [14]. 

Polymorphism uses type variables a, ft, . . . as placeholders for irrelevant types. 
We can prove x e {x} where x has type a (so {x} has type SET(a)) and use 
the instances of this theorem obtained by replacing a with any type. The length 
operator Len of untyped set theory becomes a polymorphic function with type 
LlST(a) -> Nat; we can think of Len as a collection of separate functions, one 
for each type a. Polymorphic equations like Len(Reverse(L)) — Len(L) can be 
proved without specifying the type of Us elements. 

A more interesting example involves the powerset operator, which has type 
SET(a) -> Set(Set(oO). (Recall that the simple type system for ZF gives pow- 
erset the type Set — > Set.) Polymorphism lets us write terms like V(P(S)) in 
which the operator appears with two different types. Most proof assistants for 
higher-order logic automatically type check such terms [15, 34, 38]. 

3.3 Disjoint Sums and Datatypes 

Properly implemented, polymorphism lets us write specifications that hardly ever 
mention types. But the types are still there, and they constrain what we may write. 
In A U B, the sets A and B must have the same type. Sometimes this restriction is 
reasonable, but often it is not. If A is a set of apples and B a set of bananas, then 
it is unreasonable to prohibit the set A U B of fruit. The standard way to write this 
set in higher-order logic is to define the new type Fruit to be the disjoint union of 
the existing types Apple and Banana: 

datatype Fruit = Apple Apple | Banana Banana 

In addition to declaring the type Fruit, this declaration introduces the constructor 
functions Apple : Apple -+ Fruit and Banana : Banana -> Fruit, as well 
as other functions for case analysis. 

The function Apple maps from apples to fruit, but we also need to map from 
sets of apples to sets of fruits. For this purpose, we can use the image operator ", 
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defined informally by 

f"S 4 {f(x)\xeS}. 

(This definition is easily formalized in higher-order logic.) If A has type 
Set(Apple) and B has type Set(Banana), then Apple" A U Banana il B has 
type Set (Fruit). 

Datatype declarations can be recursive. Here is the definition of lists in terms 
of two primitive functions, the empty list Nil and the constructor function Cons 
that takes arguments of types a and LlST(a). 

datatype LlST(a) = Nil | Cons(a, LiST(a)) 
Datatype declarations can be reduced to the underlying logic [29]. 

3.4 Sets in Higher-Order logic 

The simple types of higher-order logic are too restricted a notion of collection 
to replace sets. To write practical specifications, we need set- theoretic operators 
such as union and set comprehension. We could add appropriate set theory axioms 
to typed first-order logic and then develop mathematics more or less as in ZF. 
However, it is more convenient to develop typed set theory within higher-order 
logic, adopting functions as a primitive concept instead of coding them as sets 
of pairs. This permits quantification over predicates, which are variables of type 
x ->• Bool. 

A practical type system for higher-order logic should provide several ways of 
expressing types: 

• Type variables a, /3, y, . . . for polymorphism. 

• Basic types such as Nat and Real, including the type Bool of logical 
formulas. 

• Type operators including the operator — >• such that a — ► r is the type of 
functions from type a to type x. 

• Datatype declarations. 

Type checking is decidable, using the Hindley-Milner algorithm [30]. The algo- 
rithm even infers the types of variables occurring in expressions. This kind of type 
system is used in the functional programming languages Haskell [22] and ML [40], 
since one may write code that is not only polymorphic, but almost entirely free of 
type declarations. It works well in logic too. 
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Sets of elements of type r are represented as predicates over type r. We define 
Set (a) to be a — >• BOOL and make the following polymorphic definitions of set 
operations: comprehension {x \ P(x)} equals kx.P(x), x e S equals S(x), and V 
and |J are defined by 



The operator |J has type Set(Set(oO) ->• SET(a). The other set-theoretic opera- 
tors described in Section 2 have similar counterparts in higher-order logic. 

In set theory, operators such as V are different from functions. In higher-order 
logic they are (polymorphic) functions; there is no need to distinguish between 
functions and operators. 

Much of the discussion of sets in Section 2 carries over to their representation in 
higher-order logic. Higher-order logic traditionally includes the operator choose. 
It can adopt the same treatment of recursive functions and recursively defined sets. 
As in untyped set theory, we can let 1/0 have some unspecified value. Since 1/0 
has type Real, its value is a real number and thus is not completely unspecified. 
In principle, this can be a problem — for example, it could allow us to prove the 
correctness of an algorithm that evaluates 1/0 during its execution. In practice, 
this is seldom an issue. 

3.5 More Sophisticated Type Theories 

The simple type theory we have just described is a starting point. We now consider 
some enhancements that have been added to try to create a more powerful working 
formalism. 

3.5.1 Subtyping 

In simple type theory, a term has at most one type. We can't consider a value of 
type Nat also to be of type Int; we can only define an injection t : Nat -> INT 
that converts naturals into the corresponding integers. Addition of natural numbers 
and addition of integers are different operators with different types. (Overloading, 
discussed below, does allow us to use the same symbol + for both of them.) 

An obvious extension to simple type theory is to allow one type to be a subtype 
of another. Naturals can be a subtype of integers, and text files a subtype of files. 
Then, n : Nat implies n : Int, and we don't need the injection t. But such simple 
subtyping is not enough. It does not solve the problem, posed in the introduction, 
of the expression (i — j > 0) (A[i — j] — A[i — j]), where A is an array of 
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type NAT -> Nat, and i and j are variables of type Nat. We tacitly assumed that 
"— " is ordinary subtraction on integers, so it has type INT x INT — >• Int. 6 Simple 
subtyping does not allow us to type check this expression. Declaring A to have 
type Nat -> Nat does not imply that it has type Int -> Nat. 

This problem can be solved with predicate subtyping, a strong form of subtyp- 
ing used in the proof assistant PVS. Predicate subtyping allows us to declare Nat 
to be the subtype of Int such that n : Nat iff n : Int and n > 0. The expression 
(i —j > 0) (A[i —j] = A[i — j]) then type checks with the original declarations 
of i, j, and A. 

In general, predicate subtyping allows type expressions to contain arbitrary 
predicates, so they essentially become set comprehensions. It enables us to define 
the subtype Real^o of nonzero real numbers and give the reciprocal function recip 
the type Real^o — ► REAL. The question of what 1/0 means never arises; an 
expression is not type correct if its meaning depends on the meaning of 1 /0. Type 
checking of any expression would include proving x ^ 0 for every occurrence of 
l/x. Context can be used, so (i / 0) (i • (1/aO — 1) is type correct. But, 
with predicate subtypes, type checking is undecidable; the user must prove the 
type-correctness theorems that the type checker cannot. 

3.5.2 Overloading 

Overloading means letting one symbol stand for many different functions, using 
types to determine which function is intended. The symbol "+" could denote ad- 
dition over types NAT, INT, and Real. Because it eliminates the need for different 
versions of the operators over the numeric types, overloading may be seen as an 
alternative to subtyping. However, injections among the types are still required. 

Haskell's type classes [44] support overloading in a controlled fashion, ensur- 
ing that symbols are shared only among suitably related types. They treat over- 
loading as a generalization of polymorphism. Type classes were invented for use 
in functional programming and are implemented in the proof assistant Isabelle [38]. 

However, overloading is probably not the best way to promote flexibility in 
notation because it can lead to confusion. In any case, it is not a decisive reason to 
prefer a typed language to an untyped one, so we will not discuss it further. 

6 There is no problem if one defines "— " to have type NAT x NAT — »• NAT; but declaring 1—2 
to be a natural number is a way of pretending the problem doesn't exist, not of solving it. A system 
that does meaningful type checking and allows the type NAT should not only allow (i — j > 0) 
(A[i — j] = A[i — j]), it should also disallow (i — j > 0) =>• (A\j — i] > 0) when A has type 
Nat -> Nat. 
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3.6 Constructive Type Theories 

A number of type theories, such as the Calculus of Constructions [5], have been de- 
signed as constructive alternatives to classical set theory. Constructive reasoning — 
whether typed or not — is concerned with what we can know, as opposed to what 
might be true "out there" [8]. This shift of emphasis rejects basic laws of classical 
logic, even the "obvious" tautology P v ->P. Constructive logic accepts the truth 
of every integer is either even or odd, but only because we have an effective means 
of determining which alternative holds for any integer. It does not accept the state- 
ment every real number is either rational or irrational; given a real number, say as 
a convergent series, we have no effective means of determining whether or not it is 
rational. Constructive logic makes distinctions that are lost in classical logic. For 
instance, 3x . P(x) is a stronger assertion than ->(Vx . ->P(x)), since the former 
implies that we can compute the value claimed to exist. 

Formally, we do not say "A is true," but "a is a proof of A" and write a e A. A 
proof of the conjunction A A B consists of a proof a of A and a proof b of B; thus, 
a proof of A A B has the form (a, b) for a € A and b e B. Clearly, if we regard 
A and B as sets or types, then A A B is precisely the Cartesian product A x B. 
Constructive type theories identify each formula with the type of its proofs. 

Similarly, a proof of A v B either has the form Inl(a), for a e A, or Inr(b), 
for b e B. The disjunction is simply the disjoint sum A + B. (The Inlllnr tag 
indicates whether the attached proof verifies A or B.) A proof of A B must 
provide a proof of B given a proof of A. It is a function / such that f(x) e B if 
x e A. Constructive type theories represent implication by the type A — > B of 
functions from A to B. 

Quantifiers, viewed constructively, yield dependent types. A proof of 3x e 
A . B(x) consists of some element a of A paired with a proof of B(a). The corre- 
sponding set or type is written ^x e A . B(x) and consists of all pairs (a, b) such 
that a e A and b e B(a); it generalizes the Cartesian product A x B by letting B 
depend upon elements of A. A proof of Vx G A . B{x) consists of a function / that 
gives a proof f(x) of B(x) if x € A. The collection of all such functions is written 
\~[x e A . B(x); it generalizes the function space A — >• B by letting B depend 
upon elements of A. For example, if NLlST(n) is the type of lists of length n, 
then the function / that maps each natural number n to the list [1, 2, . . . , n] has 
the dependent type f] n e Nat . NLlST(n). 

Constructive type theories achieve conceptional economy by identifying A 
with x, V with +, 3 with E, V with n, etc. They can use the same primitives 
on collections as they do on logical propositions. Their lore is too deep for us to 
examine here; look elsewhere for explanations of universes, impredicativity, inten- 
sional equality and other mysteries. 
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For expressing specifications, constructive type theories are no more powerful 
than the classical systems we have examined above. The S and n constructions 
can also be defined in both untyped set theory and in the typed set theory of higher- 
order logic. Classic ZF texts define n [20, page 36], and £ has a simple definition. 
PVS's predicate subtypes provide the effect of £ and n at the level of types. 

The main virtue of these type theories is precisely that they are constructive. A 
constructive proof that two arbitrary numbers always have a gcd provides an algo- 
rithm for computing it [43]. Researchers, using tools such as Coq [7] and Nuprl [4], 
are investigating whether this can lead to a practical method of synthesizing pro- 
grams. 

You can perform classical reasoning in a constructive type theory by adding 
P V->P as an axiom. The resulting system will probably be strong enough to handle 
any specification problem likely to arise. However, it will be no stronger than ZF, 
and it will be much more cumbersome to use. If you want classical reasoning, 
use a system designed for that purpose. Since most computer scientists do prefer 
classical reasoning, constructive type theories are not widely used. We will not 
consider them further. 

4 Sets Versus Types 

Having described set theory and typed formalisms, we now compare them — first 
for writing specifications, then for reasoning about them. We also cast a more 
critical eye on predicate subtyping. 

4.1 Specification 

Our comparison of set theory and typed formalisms for writing specifications is 
partitioned into four rather arbitrary categories: flexibility, convenience, pitfalls, 
and abstractness. 

4.1.1 Flexibility 

Set theory is more flexible than typed systems. This flexibility is evident in the 
ability to model objects with sets, described in Section 2.7.3. To construct a set of 
all objects, we need to write sets like |J{5j : i G S}, the union of all sets B>i with 
i e S. No simple typed formalism that we know of admits |J{-Bi : i € S} as a 
type. It is a set in a typed set theory only if P>i has the same type for all i in S, 
which might require the use of disjoint sums. 

Object-oriented type theories are being investigated [11], and perhaps a simple, 
elegant one can be found. However, objects are just one example of the diverse 
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mathematical concepts that arise in real specifications. (In the application that 
led to this example, objects were needed to represent the system, not because we 
wanted to write an object-oriented specification.) We cannot expect to find type 
systems ready-made for each new concept — let alone for combinations of them. 
But set theory's flexibility should enable it to take new developments in stride. 
Indeed, one application of set theory is in modeling novel recursive structuring 
principles that can be used in the design of new type theories [37, 39]. 

The flexibility of set theory is also useful in more mundane circumstances. The 
Copy operator defined in Section 2.7.2 appears in a specification of a distributed 
system written in part by the first author. The specification describes actions in 
which a node receives a message m of one type and sends one or more messages 
of different types containing many of the fields from m. Using Copy instead of 
listing the fields to be copied makes the specification shorter and clearer. In a typed 
system, one would need a separate Copy operator for each pair of types, which is 
not feasible. Instead, one would define a single message type containing all the 
fields from all messages, and would ignore irrelevant fields in specific messages. 

The typed specification is easy enough to write, but having a single type for all 
messages makes it essentially untyped. The set-theoretic specification is, in effect, 
strongly typed: it distinguishes among the individual message types. This example 
is typical of large specifications. It can be written in a typed formalism, but set 
theory permits simplifications that would probably not even occur to someone who 
has used only typed formalisms. 

4.1.2 Convenience 

One argument against typed formalisms is the inconvenience of having to attach 
type constraints to all variables. This is at most a minor point, and it does not apply 
to a well-designed language based on higher-order logic with type inference. Type 
inference propagates type information, rendering most type declarations unneces- 
sary. From the single declaration 0 : Nat and the expression 0 e A U {x, y], we 
can infer automatically x, y : Nat and A : Set(Nat). The standard type inference 
algorithm has been proved to be sound [30] and enjoys other strong properties; for 
instance, it always finds the most general type possible. Subtyping complicates 
matters considerably. If Nat is a subtype of INT, the declaration 0 : Nat does not 
determine the type of any variable in 0 e A U [x, y}. Mitchell [31] has proposed a 
type inference algorithm to handle coercions between atomic types, but subtyping 
clearly limits what can be inferred automatically. 

Conversely, it can be argued that types make writing specifications more conve- 
nient because they make implicit parts of the specification that must be expressed 
explicitly in an untyped formalism. Automatic type inference can deduce that x 
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is of type Nat in cases where a set-theoretic specification would need the explicit 
assumption x e Nat. However, the simple type system that makes type infer- 
ence possible would force us to write i(x) — i(y), where i is the injection of type 
NAT -> INT, in cases where the set-theoretic specification would let us simply 
write x — y. Whether type inference helps more than injections hurt will depend 
on the particular specification. 

4.1.3 Pitfalls 

By "pitfalls", we mean subtle aspects of a formalism that can lead unwary users 
to write specifications that don't mean what the users think they do. We illustrate 
some pitfalls using an action formalism, in which a system is specified by an ini- 
tial predicate and a next-state relation, which is a predicate relating old and new 
values [21, 26]. For example, a nonterminating program in which n is initially 
0 and is continually decremented by 1 is specified by the initial predicate n — 0 
and the next-state relation n' = n — 1. This next-state relation is equivalent to 
the programming-language statement n :— n — 1, but action formalisms allow 
you to write next-state relations such as n = n' + 1 that have no counterpart in a 
conventional programming language. 

One would expect the next-state relations n' — n — 1 and n — n' + 1 to be 
equivalent. They are in a typed formalism, if n is declared to have a numeric type 
such as Nat or Int. They are not equivalent in an untyped formalism like ZF. 
For example, there could be some nonnumeric value v, different from 3, such that 
4 = v + 1, so 4 = n' + 1 does not imply n! — 4 — 1. The next-state relation 
for a program that continually decrements n by 1 can be written in set theory as 
n' = n — 1 or (n = n' + 1) A (n' e Int), but not as n = n' + l. 7 The inequivalence 
of n' — n — 1 and n = n' + 1 is a minor nuisance. But, it could lead unwary users 
to write n — n' + 1 when they mean n' — n — 1 . 

This pitfall is avoided in a typed system because declaring n to have type Int 
asserts the assumption that n and n' are integers. However, such assumptions lead 
to a different pitfall. If we declare n to have type Nat, then we are assuming n > 0 
and n' > 0. Hence, n' — n — 1 is equivalent to (n' — n — 1) A (n > 0). Thus, 
n' — n — 1 represents not the usual assignment statement n : = n — 1, but the 
semaphore operation P{n). This means that Int h F does not imply Nat h F, if 
F is the formula asserting that n' = n — 1 is enabled. It is quite easy to forget that 
the next-state relation n! = n — 1 is not always enabled, and this can lead to errors. 
Indeed, the first author once fell into this trap and wrote incorrect proofs for a few 
algorithms. 

'Defining "+" so m + n is a number iff m and n are both numbers does make n' = n — 1 and 
n = n' + 1 equivalent as next-state relations for a system in which n is initially a number. 
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Subtlety is in the mind of the beholder. A subtle trap for the naive user is an ob- 
vious error to the expert. An experienced user of a formalism may find it perfectly 
simple and think that only other formalisms have subtle pitfalls. Set theory and 
higher-order logic both have their pitfalls; there is no reason to believe that either 
has fewer than the other. However, complexity usually leads to subtle problems, so 
we might expect more pitfalls in a more complicated type system. 

4.1.4 Abstractness 

Mathematicians typically define objects by explicitly constructing them. For ex- 
ample, a standard way of defining N inductively is to let 0 be the empty set and n 
be the set {0, . . . , n — 1}, for n > 0. This makes the strange-looking formula 3 € 4 
a theorem. 

Such definitions are often rejected in favor of more abstract ones. For example, 
de Bruijn writes [6, §3]: 

If we have a rational number and a set of points in the Euclidean plane, we 
cannot even imagine what it means to form the intersection. The idea that 
both might have been coded in ZF with a coding so crazy that the intersection 
is not empty seems to be ridiculous. 

In the abstract data type approach [19], one defines data structures in terms of their 
properties, without explicitly constructing them. 

The argument that abstract definitions are better than concrete ones is a philo- 
sophical one. It makes no practical difference how the natural numbers are defined. 
We can either define them abstractly in terms of Peano's axioms, or define them 
concretely and prove Peano's axioms. What matters is how we reason about them. 
If we use only Peano's axioms, then we will never prove 3 e 4, even if it should 
happen to follow from our definition of the natural numbers. 

Experience with abstract data types has shown that defining data structures ab- 
stractly in terms of their properties is error-prone. It is easy to write inconsistent 
or incomplete lists of properties. When there does not already exist a well estab- 
lished mathematical characterization of a data structure, one is better off defining 
it explicitly in terms of sets and functions. 

Even though we define data types explicitly, experience with large programs 
shows that it is important not to "break" an abstraction by making use of its under- 
lying representation. An abstraction can be enforced by some form of modularity 
that hides the representation from users of the abstraction. Such hiding works for 
both typed and untyped specifications. 
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4.2 Verification 



One reason for writing a specification is to allow a subsequent verification. To say 
that a program (or hardware design) is correct means that it meets its specification. 
Some programs are verified by hand. Others are verified using proof tools. But 
most are not verified at all, even those that have been specified formally. We now 
consider what these alternatives imply about the choice of a formalism. 

4.2.1 Specification without Verification 

Verification is difficult and time-consuming. For most real systems, it is pro- 
hibitively expensive. But the very act of writing a formal specification catches 
errors, omissions, and ambiguities early in the design process [12]. This is the 
main objective of the popular specification languages Z and VDM. Such specifica- 
tions are seldom intended for use in proofs. 

Type checking can find errors in these specifications. This is a good reason for 
choosing a typed formalism. However, there may be other ways of finding errors. 
We envision a system in which an untyped specification can be augmented with 
typing annotations that are checked by machine. This approach is highly flexible. 
The "type system" could exploit the full power of set theory, perhaps in unusual 
ways. We could safely ignore "type errors"; our set theory is untyped, after all. 

Analogous approaches have already been adopted for programming languages. 
Soft typing [46] is one attempt to combine the advantages of untyped and typed 
programming languages. Modula-3 is strongly typed but provides loopholes in 
order to achieve the flexibility needed for writing systems programs [32]. 

A checker for typing annotations could combine the advantages of type check- 
ing with the generality of set theory, but building it is a research project. Now, if 
one wants the advantages of type checking, one must use a typed formalism. 

4.2.2 Verification by Machine 

Although not all specifications will serve as a basis for mechanical verification, the 
desire for machine-checked proofs may affect the choice of a formalism. 

Type checking finds errors that, in an untyped system, must be caught when 
writing a proof. It can be argued that type checking saves work by catching errors 
earlier. However, type errors are generally trivial compared to the subtle errors 
that the proof process is designed to catch, and they are usually caught early in the 
proof. Indeed, one can argue that type checking wastes time by forcing the user to 
correct type errors in formulas that are later discarded because they turn out to be 
wrong or unnecessary. Neither argument carries much weight. Type checking can 
save work by catching an error early, and it can create extra work by forcing one 
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to type check an unnecessary formula, but the amount of time saved or wasted is 
almost always negligible. 

A more compelling argument in favor of typed formalisms for mechanical ver- 
ification is that the type checker can automatically deduce facts that have to be 
asserted as lemmas with an untyped formalism. Suppose we want to prove that 
(x + 1) + y — y + (x + 1) for real numbers x and y. In an untyped system, we 
would use the proof rule 

Vr, s eR.r + s = s + r (6) 

To apply that rule, we must first prove x + 1 € R, using the rule 

Vr, seR.r + seR 

In a typed system, we would be proving (x + 1) + y — y + (x + 1) when x and y 
are of type Real. The analog of (6) in a typed system is simply 

r + s — s + r (7) 

where "+" has type Real x Real -> Real. One can apply (7) directly to deduce 
(x + 1) + y = y + (x + 1). 

Logically, there is no difference between the untyped and typed proof. To apply 
(7), the typed system must type check the expression (x + 1) + y, which requires 
checking that x + 1 is of type Real. Hence, it has to prove the same lemma that 
must be proved in the untyped proof. The two proofs are completely isomorphic, 
where one writes r e R in the untyped proof and r : Real in the typed proof. 
An untyped prover could automatically prove theorems that correspond to type 
correctness. In fact, the Nqthm theorem prover [2] uses type information internally, 
even though the logic is untyped. Still, the untyped prover ends up doing extra work 
to prove type-correctness lemmas like x + 1 e R; unless precautions are taken, it 
may prove the same lemmas repeatedly. In ACL2 [25], an untyped theorem prover 
for an applicative subset of Common Lisp, the user can provide type declarations 
as hints to get the system to automatically deduce the same facts that a type checker 
does in a typed system. 

Applying the conditional rewrite rule implicit in (6) is sufficiently difficult with 
current untyped systems that one often tries to avoid the problem by artificially 
extending the definition of "+" so that (6) holds unconditionally: 8 

Vr, s.r + s = s + r (8) 
8 Boyer and Moore use this technique extensively to ensure that all functions are total. 
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For example, we can define 

r + s = if r, seR then . . . else nonreal (9) 

where nonreal is some arbitrary value not in R. However, this approach cannot 
completely avoid the need to use type information in proofs. For example, redefin- 
ing "+" and "— " in this way will not make n' — n — 1 and n — n' + 1 equivalent 
for nonnumeric values of n and n' . 

The mechanical verification systems that have so far been most successful are 
probably HOL [15] and the Boyer-Moore prover [2]. Both systems have been used 
for over a decade to verify many systems. HOL uses higher-order logic, while the 
Boyer-Moore system is untyped, though it is not based on set theory. PVS [34], 
based on predicate sub typing, has recently become quite popular. Tools for ZF, 
such as EVES and Isabelle/ZF [36], are emerging; other axiom systems for set 
theory, such as Bernays-Godel, are also suitable for automation [41]. It seems 
impossible to draw any conclusions about the superiority of typed or untyped for- 
malisms from experience with existing verification systems. The most significant 
differences among them lie in such issues as the user interface, decision procedures, 
extensibility, and the ability to write proof tactics — not in whether the formalism 
is typed. 

4.2.3 Verification by Hand 

Any advantages that typed formalisms might have for mechanized proofs do not 
apply to hand proofs. One might try to argue that, even if the proof is done by hand, 
one could still use a type checker to catch some errors. However, automatic type 
checking is possible only for simple type systems. The errors caught by such type 
checking are mathematically trivial; they would be easily caught by any reasoning 
rigorous enough to be called a proof. Type checking will catch the error sooner, but 
our experience writing hand proofs indicates that this would not save a significant 
amount of time. 

When reasoning by hand, it makes little difference if the formalism is typed or 
untyped. What matters is how simple the theorem is that one is trying to prove. 
Because of its greater flexibility, set theory can allow a simpler statement of a 
theorem than a typed formalism. 

4.3 The Trouble with Predicate Subtypes 

Predicate subtypes provide an appealing solution to the problem of the expression 
(i — j > 0) (A[i — j] = A[i — j]). They seem to add the advantages of sets to 
a typed formalism. However, they introduce their own problems. 
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initially n — 0; s = [ ] 

do true -> n : — n + 1; s : — s © [42] 
D 

n>0 -> n : = n — 1; s : = Tail(s) od 
Figure 3: A simple algorithm. 

One problem with predicate subtypes is that they restrict how one can decom- 
pose definitions. They permit the definition 

P 4 (i-j > 0 )^(A[i-j] = A[i-j]) 

but not the pair of definitions 

Q = A[i-j] = A[i-j] 
P A {i-j>0)=*Q 

The definition of Q does not type check. (Note that i and j are variables declared 
elsewhere, not parameters of the definition.) To write this, one would need a sepa- 
rate kind of "macro" definition (perhaps akin to C's # de f i ne directive) that defers 
type checking until the definition is used. Formulas in specifications can be very 
large. Reasoning about a large formula requires defining it in terms of subformulas 
whose definitions are expanded only as needed. Restrictions on what subformulas 
can be defined may be burdensome. 

Another problem with predicate subtypes is illustrated by the program of Fig- 
ure 3. The program uses Dijkstra's do construct 

do g\ ->• s\ D . . . D g n s n od 

which is executed by repeatedly choosing an arbitrary % such that gi is true, and 
executing S{. The statement terminates when all the gi are false. Tail and © (con- 
catenation) are the usual operations on sequences, and [] is the empty sequence. 
The program of Figure 3 loops forever, nondeterministically adding and removing 
42s from the sequence s, while keeping n equal to the length of s. We consider the 
proof that the program never sets s to Tail of the empty sequence. In a formalism 
based on set theory, we prove that the assertion (s e List(N)) A (n — Len(s)) 
is an invariant of the program. What do we do in a formalism based on predicate 
subtypes? 

With predicate subtyping, Tail would have type LlST ne (a) — > LlST(a), where 
LlST ne (a) is the subtype of LlST(a) consisting of nonempty lists of elements of 
a. If we let n have type Nat and s have type List(Nat), then the program of 
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Figure 3 does not type check because Tail is applied to an expression of the wrong 
type in the last clause of the do statement. The problem can be made to go away 
by adding the extra test s ^ [ ] to the second guard. But verification means proving 
the correctness of a given implementation, not finding an implementation whose 
correctness one can prove. 

In general, the type declarations of the program variables will have to encode 
an invariant of the program. In the worst case — which is probably not uncommon 
for algorithms that employ "partial functions" like Tail and division — the type 
declaration will have to include a large part of the invariant needed to prove the al- 
gorithm correct. Type checking requires performing a major part of the correctness 
proof and can be quite difficult. Type declarations are likely to be an awkward way 
of expressing an invariant. 

With predicate subtyping, type checking is undecidable and often requires hu- 
man intelligence. A well-designed verifier will handle the easy cases automatically 
and generate proof obligations for the rest. Predicate subtypes can be useful for 
increasing the flexibility of the type system in a theorem prover. However, the ex- 
tra flexibility comes at the price of making some specifications awkward to write. 
Even with predicate subtyping, a typed formalism is significantly less flexible than 
set theory. Moreover, the subtyping rules of PVS are not simple, and have caused 
several bugs that violate soundness. For example, a recent PVS release note reads 
in part [33]: 

Soundness bug 160 is due to subtype constraints being asserted out of 
context. The subtype information in B for the expression A AND B 
should not be asserted globally since the subtyping might depend on 
the context A. 

5 Conclusions 

The advantages of types in programming languages are well known. Few people 
are aware of the problems they can introduce in a working formalism for spec- 
ifying and reasoning about computer systems. A simple type system prohibits 
the simple formula (i > 0) =>• (A[i] > 0) if i has type INT and A has type 
NAT — > Nat. Predicate subtypes constrain how we can decompose formulas and 
can require quite complicated type declarations. Set theory provides a simple, 
powerful alternative that avoids these problems. 

A working formalism should be designed on practical grounds. For types to be 
worth using, they must offer some benefit. That benefit can lie only in the realm of 
computerized tools. Without mechanical support, types have nothing to offer; set 
theory's greater flexibility makes it better suited to writing hand proofs. 
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The most obvious tool is a type checker. Simple type checking can catch er- 
rors in specifications. Those errors are easy to catch with rigorous proofs. How- 
ever, many specifications are never verified; they can benefit from automatic type 
checking. But typed formalisms that permit automatic type checking are less flexi- 
ble than set theory. The best way to catch errors may be to treat type declarations as 
annotations that do not affect the meaning of the specification. If the type system 
proved to be too inflexible, one could replace it by a different one or simply ignore 
certain type errors. 

Another important class of tool is a mechanical theorem prover. Mechanical 
proofs in set theory tend to require more human guidance than proofs in a typed 
formalism. Type checking establishes results that otherwise have to be proved 
as theorems about set membership. However, untyped pro vers can already prove 
some "type-checking" results automatically, and we can expect such implementa- 
tions to improve. Eventually, provers based on set theory may provide the benefits 
of type checking together with the ability to write specifications that cannot be type 
checked. 

Model checkers are becoming increasingly popular, since they provide the 
guarantees of theorem proving with little human effort. Model checking, which 
in principle involves exhaustively checking all possibilities, can work only on a 
restricted class of specifications. This class of specifications can be defined by 
adding a quite restrictive type system to an untyped formalism based on ZF, so the 
class consists of all type-correct specifications. This approach is currently being 
pursued by colleagues of the first author. 

Set theory is particularly appealing as a single formalism that can be used for 
a range of diverse and unforeseen applications. For each application, there may 
exist a type theory that is ideal for it. But it is unlikely that any type theory can 
be good for all applications. Universal formalisms do not exist in the real world; 
set theory is as close to one as we are likely to get. Now, mathematical theories 
must be redeveloped from scratch for each new verification system. The use of set 
theory as a common foundation could make possible the sharing of results between 
these different systems. 

We believe that the generality of set theory can be combined with the bene- 
fit of type-based tools by viewing a type system as just a way of imposing well- 
formedness conditions on formulas. We can overlay different type systems atop 
untyped set theory, choosing the one that is suited to the particular tool we want to 
use. This is equivalent to defining a sublanguage of set theory to be translated into 
the language of the tool. The approach was used in TLP [9], which translated from 
an untyped, ZF-based first-order language into LP [13], a typed logic that (at the 
time) lacked quantifiers. We believe this technique can be applied more generally 
and merits further research. 
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